Two of the three fix directions on the issue. The third is a product
decision, not a patch, and is left alone deliberately.

**staleDate on Live Activity content.** The app declares no background
modes and requests the activity with `pushType: nil`, so iOS suspends the
WebSocket within seconds of backgrounding and nothing can update the
activity until the app is opened again. With `staleDate: nil` the lock
screen kept presenting that last temperature as current, indefinitely,
across an 8-12 hour firing. For a number an operator may act on, wrong
and confident is worse than visibly out of date. 90s: the firmware
broadcasts every second, so any longer gap is already abnormal, but it is
loose enough to ride out a Wi-Fi blip while foregrounded without
flickering to stale.

The terminal content keeps `staleDate: nil` on purpose — "Complete" is
not a reading that decays, and ageing it would make a finished firing
look like a lost connection.

**Resync on foreground.** `scenePhase == .active` now refreshes status
over REST and then restarts the socket. Previously the socket came back
dead while `connectionState` still read `.connected`, so returning to the
app mid-firing showed the reading from whenever the phone went into a
pocket until the user happened to pull to refresh.

REST before reconnect, because the snapshot is what makes the screen
correct immediately; reconnecting alone leaves it wrong until the next
broadcast. `resumeIfConnected()` is a no-op unless a connection was
already established, so a foreground event cannot start dialling a kiln
the user never connected to, or paper over an `.error` they still need to
read.

**Not fixed: background delivery.** The "Kiln Error / check kiln
immediately" notification still requires the app to be running, which is
the safety gap the issue is really about. Closing it means either wiring
the firmware's existing webhookUrl to a push bridge, or an APNs relay for
ActivityKit push tokens — infrastructure choices for a LAN-only device,
not something to pick unilaterally. #147 stays open for that.

Not verified by compilation: no Swift toolchain on Linux. CI's build-ios
job is the only compile check, and staleness rendering plus scenePhase
transitions need a device to confirm.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PyJ47o5sWvpb9vMk1RNKkb

… churn

Four review findings, three of them P1 and two of them introduced by the
first pass of this PR.

**staleDate was inert.** Setting it only flips `ActivityViewContext.isStale`;
ActivityKit does not alter the rendering. Neither the lock screen nor the
Dynamic Island read that flag, so the frozen temperature went on looking
exactly as current as before — the PR claimed a behaviour change that did
not happen. Both presentations now dim the reading and, where there is
room, say why. The countdown is *replaced* rather than dimmed: "~2h
remaining" extrapolated from a frozen frame is a claim, not a stale
observation.

**The foreground resync caused continuous socket churn.** disconnect()
cancels the receive loop's task and socket, but the loop reaches its catch
block regardless (`Task.isCancelled` guards loop entry, not the catch) and
hops to the main actor to schedule a reconnect — by which time connect()
has already set shouldReconnect back to true. That reconnect then cancels
the healthy socket, whose loop schedules the next one, at 1-8s intervals,
indefinitely. Worse than the bug being fixed.

Each openConnection() now stamps a generation; a loop reports its socket
lost only while its own stamp is still current. Cancelling the task alone
would not do: openConnection() can supersede a loop that was never
cancelled. disconnect() bumps it too, so an explicit disconnect silences
its loop by generation rather than relying on shouldReconnect.

**A transition that happened while suspended was swallowed.** refreshAll
assigned previousStatus directly, so a firing that completed in the
background was adopted without running handleStatusTransition — and the
next frame carried the same status, making the difference undetectable
forever. The Live Activity was never ended and peakTempC carried its
high-water mark into the next firing's completion notification: the same
lie #146 was about, by a different route. Snapshots now run the
transition, gated on hasObservedStatus so the first load after launch does
not announce a firing the app never watched.

That gate is applied to the WebSocket path too, where the same spurious
announcement was possible on a first frame of "complete".

**Status no longer waits on unrelated requests.** refreshAll awaited
status, profiles and settings together, so a failure or stall on either of
the latter discarded a good status and — on foreground — held the socket
restart behind it. Status is now its own method; the foreground path calls
that and reconnects, leaving profiles and settings to connect time and
pull-to-refresh.

Still not compiled: no Swift toolchain on Linux, so CI's build-ios job
remains the only compile check.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PyJ47o5sWvpb9vMk1RNKkb